home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0016-Re TDocument Limita-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  2.8 KB  |  57 lines  |  [TEXT/GEOL]
  1. Item    9762259                         6-June-89        12:02
  2.  
  3. From:   ALGER                           Alger, Jeff
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Re: TDocument Limitations
  8.  
  9. Curtis (and everyone else who has responded),
  10.  
  11. You have stumbled over the tip of a very large iceberg.  The problem here is
  12. not simply the command handling of MacApp, but the fact that MacApp and the
  13. Desktop Interface address only the simplest of applications.  You, Chris
  14. Arbogast, Chris Le Croy, and Les Caudle all made the same point to differing
  15. degrees.
  16.  
  17. The paradigm of a "document" as the natural division of the user's data simply
  18. does not map into any database environment.  Take the old parts-suppliers
  19. problem of database theory: each part is supplied by many suppliers and each
  20. supplier supplies many parts, with prices determinable only by combinations of
  21. a part and a supplier.  What is the "document"?  Is there one document per
  22. supplier?  One per part?  One for the whole database?  Suppose we extend this
  23. to a database with 100 entities and 1000 attributes, all closely interrelated?
  24. Suppose the user is allowed to dynamically create new database files and
  25. relationships?
  26.  
  27. I disagree STRONGLY with the notion of the entire database as the document, at
  28. least after the program has been launched and the user is faced with "New" &
  29. etc. in the File menu.  This is not useful to the user or to the program.
  30. Furthermore, it falls of its own weight as soon as you consider distributed
  31. databases or even multiple open databases on the same machine which can be
  32. queried as one.  It is at best a stopgap way of mapping the freewheeling
  33. environment of database management and query languages into the rather
  34. simplistic world of the document-application-oriented desktop.
  35.  
  36. Hierarchical models of data have proved unwieldy in practice; there are good
  37. reasons why network and relational models have replaced them.  Yet, the idea of
  38. division of data into documents is clearly a throwback to hierarchies.  In the
  39. parts-supplier problem, one can argue equally strongly for division based on
  40. parts and based on supplier (do you take orders from customers or place orders
  41. with suppliers?!?)
  42.  
  43. I am now working on my third major project in MacApp which involves
  44. front-ending database management systems.  TDocument has been more of a
  45. hindrance than a help in each case, at least insofar as representing the
  46. database is concerned.  Something is missing here.
  47.  
  48. What is the correct solution?  I don't know: it is something that constantly
  49. nags.  However, perhaps the time has come for a full-fledged dialog on the
  50. issue.  Out of the collective wisdom of MacApp.Tech$ perhaps some solutions can
  51. emerge.  In any case, NEVER hesitate to put such issues on MacApp.Tech$.  As
  52. the level of response suggests, you have definitely touched a nerve.
  53.  
  54. Jeff Alger
  55. Peat Marwick Main & Co.
  56.  
  57.